Nowadays computational devices are used in almost every area of our daily life, and the range of hardware devices and software applications installed on such devices, as well as the possible interactions and configuration options, is expanding rapidly. The development of the Internet and wireless communication networks adds another element—communications—where each device also has neighboring devices in its environment with which it interacts and communicates. Moreover, as devices become mobile, and as networks become dynamic—with devices being attached and withdrawn to networks in an ad-hoc fashion—describing the environment of a computational device becomes increasingly challenging and, at the same time, essential for understanding its function.
Against this background, we observe that an important task in many settings is to know the state or configuration of a remote computer. For example, it can be highly desirable for a vendor or technical support provider to know details of the configuration information of such a computational device in order to provide better customer service. Indeed, when the customer is experiencing difficulties with a product of the vendor, the technical support department of the vendor often needs to know the configuration information of the customer's computational device in order to trouble-shoot the product and provide a fix to solve the customer's problem. In another application, the technical ‘help desk’ of an enterprise—charged with keeping various personal computers, servers, and other network devices in good operating order—may need to know the configuration information of one or more such computational devices to perform trouble shooting or routine maintenance tasks. In another application, the manager of a ‘server farm’—charged with offering services across the Internet from an array of computational devices—may need to know the process status of one or more server devices.
We remark that the term configuration is best interpreted in a broad sense, including the location of mobile devices, the status of connected devices, the status of links to connected devices, the activity and configuration of devices in proximity, and the status of remote devices in a relationship of trust and intimacy.
In the current state of art, the method of requesting, gathering and transmitting of configuration information of a computational device is often informal, manual, insecure, and time-consuming. In the example of the technical support scenario, a support technician has to communicate with a customer over telephone (sometimes even for hours) to instruct the customer in step-by-step fashion how to collect the configuration information that the support technician needs. It is usually very tedious to explain the detailed steps that the customer must take to gather the information, and many customers are unable or unwilling to apply the concentrated effort it would require to obtain the needed information. As a result, the process—where attempted—is often frustrating and difficult. An alternative approach may include exchanging e-mails between the support technician and the customer. This approach still faces problems of customer compliance, and in addition, it exposes the configuration information of the computational device to the hackers over the Internet. Furthermore, this process—if it works at all—may require several rounds of e-mail exchange before the customer can collect the right configuration information that the support technician needs.
Still another approach might be to use remote program execution (RPE), which includes the steps of: dispatching a codebody from the requestor to the target computer; executing the codebody on the target computer; performing a computation which obtains the desired result, and returning the result to the requester. The persistent problem with RPE is security. Computational Devices offering RPE services are vulnerable to attack: if a general-purpose codebody is allowed to be remotely executed, this creates a security hole whereby hackers, impersonating the trusted authority or infiltrating the trusted domain, can insert general purpose programs which can be used to attack the remote machine. Perhaps more importantly, RPE is vulnerable to mistake, so that RPE is dangerous even in the presence of strong network security. Indeed, the configuration requestor, operating in good faith, can make a mistake in writing its query which can create an “infinite loop” or similar resource bind on the target computer, rendering the computer useless. Therefore, RPE is a dangerous option to employ.
Donoho et al disclose in U.S. Pat. No. 6,262,362 a method for inspecting the properties of a computer, the computer's configuration, the contents of the computer's storage device, the computer's peripherals, the computer's environment, or the computer's affiliated computers. The method involves phrasing queries of the computational state in a formal language, called the relevance language, and then automatically evaluating the queries in order to probe the state of the computational device. The evaluation requires first parsing a relevance clause in the relevance language, and then translating that into a sequence of desired “inspector evaluations”. Inspectors are pre-defined measurement tools resident on the target computer. They are invoked to inspect the state of the computer. The invention also provides a method to extend the relevance language by building additional inspectors.
However, in the invention disclosed in the U.S. Pat. No. 6,262,362, the configuration information of computer is only used to perform relevance determination of an advice that is received by the computer. The primary purpose of the invention was not the communication or display of the configuration information, although it mentions a need to avoid the possibility of communicating information about a target computer to other party.
What is desired is a communication network that a configuration information provider retrieves the queries from a configuration requester, interprets the queries and automatically builds a human-readable, easily understood answer set.
What is further desired is a communication network allowing a configuration provider to communicate the configuration information securely to the configuration requester.
What is further desired is a communication network allowing a configuration requester to view and compare the received configuration information from the configuration information provider.
What is further desired is that a process satisfying the above desiderata be transparent—the queries should be written in an intuitive and non-threatening language reminiscent of plain English or other natural language and the answers can be read and understood by non-experts.
What is further desired is that a process satisfying the above desiderata be safe—robust against poorly formed or mistaken queries—in fact so robust that no well-formed query can contain infinite loops and other resource-monopolizing features.
What is further desired is that a process satisfying the above desiderata is extensible—the query language can expand over time as new properties need to be examined, within a natural and secure scheme.